The current version of pyOODSM has been developed within the frames of a masters thesis. This means that there will be interesting features, that has not been explored in the current version. This sections outlines some of these features which has been left as future works.

\subsection{Better profiling}
As mentioned above, pyOODSM has been equipped with the possibility to log profiling data for objects, clients and the central server. However, the profiling scheme which has been implemented in this version is quit coarse. For instance, one can only determine whether a client is waiting for a given objects or not. It is not possible to determine how much time is spent waiting for communication and how much time is spent on the communication it self. Better profiling would be a powerful tool to help programmers to write more efficient programs based on pyOODSM, as well as helping developers of pyOODSM to optimize critical paths, in order to achieve better performance of applications based on pyOODSM.

\subsection{Detection of deadlocks}
When introducing the possibility of pinning objects to clients, we also introduced the possibility for programmer to construct deadlocks. In the current version, it is left to the user of pyOODSM to avoid deadlocks, as with the use of mutex and semaphores in a shared memory environment. A number techniques for detecting deadlock, statically or dynamically, exists according to \cite{deadlock} and \cite{deadlock2}. 

Naturally it would yield better usability if the programmers was to be helped to avoid deadlocks, however applying techniques for auto detecting deadlock would also have a negative impact on performance, at least for the dynamic methods. Further more, a lot of applications would be easy to verify for deadlocks. Therefore it should be up to the users of pyOODSM to choose whether or not to use auto detection for deadlocks.

\subsection{Read-only objects}
In cases where objects simply contains read-only data, it would be advantageous to marks such an object as read-only, i order to be able to utilize read replications or having data migration at attribute level.

The introduction of read-only objects would to some degree break the normal objects semantics of pyOODSM. Therefore such a feature should allow a user to make a special-case read-only object, leaving normal pyOODSM objects to be read-write objects, as in the current version.
